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Abstract —We present Relational Hoare Type Theory (RHTT), 
a novel language and verification system capable of expressing 
and verifying rich information flow and access control policies 
via dependent types. We show that a number of security policies 
which have been formalized separately in the literature can 
all be expressed in RHTT using only standard type-theoretic 
constructions such as monads, higher-order functions, abstract 
types, abstract predicates, and modules. Example security policies 
include conditional declassification, information erasure, and 
state-dependent information flow and access control. RHTT can 
reason about such policies in the presence of dynamic memory 
allocation, deallocation, pointer aliasing and arithmetic. The 
system, theorems and examples have all been formalized in Coq. 

Keywords -Information Flow, Access Control, Type Theory 
I. Introduction 

Several challenges persist in existing work on specification 
and enforcement of confidentiality policies. First, many practi¬ 
cal applications require a combination of a number of different 
classes of policies: authentication, authorization, conditional 
declassification, erasure, etc. Yet, most existing systems are 
tailored for enforcing specific classes of policies in isolation. 
Second, where policy combinations have been considered 
(e.g. [4, 7, 12]), policy conformance is typically formalized 
for simple languages without important programming features 
such as dynamic allocation, mutable state and pointer aliasing, 
or without modem modularity mechanisms that aid program¬ 
ming in the large. There has been little work on confidentiality 
policies pertaining to linked data structures (lists, trees, graphs, 
etc.), and even less work exists for structures that are heteroge¬ 
neous; that is, structures that contain mixed secret and public 
data as well as mixed secret and public links. Third, despite 
their efficiency, enforcement mechanisms are often imprecise 
in their handling of implicit information flow (that arises due 
to program control structures such as conditionals or procedure 
calls) and reject perfectly secure programs. 

In this paper we revisit the foundations of information 
flow — its specification as well as its static enforcement 
— and address the above challenges of policy specificity, 
language expressiveness and precision, simultaneously. The 
key insight of our work is that all the three problems can be 
addressed using standard linguistic features from dependent 
type theory [24]: (a) higher-order functions, abstract data 
types and modules, that provide for software engineering 
concepts such as abstraction and information hiding, and (b) 


a logic for higher-order assertions, including quantification 
over predicates, that serves as the foundation for a rich policy 
specification language. We additionally consider an extension 
of dependent types with (c) general recursion, mutable state, 
dynamic allocation, and pointer aliasing. We use the dependent 
types as a policy specification language, and typechecking 
(i.e., program verification) to enforce conformance of pro¬ 
grams to policy. As is standard in type theory, we assume 
that programs are typechecked before they are executed. 

As our first contribution, we show that a number of security 
policies which have been previously considered in isolation, 
such as declassification [14, 39], information erasure [15, 16], 
state-dependent access control [11, 12] and state-dependent 
information flow policies [7], can be combined in the same 
system using the mentioned type-theoretic abstractions. We 
explain this point further below, and illustrate it through 
several verified examples in the paper. 

As our second contribution, we show that these policies can 
be enforced in the presence of dynamic allocation, dealloca¬ 
tion, and pointer aliasing, and in particular, over programs 
involving linked, heterogeneous data structures. To achieve 
this, we employ a semantic definition of what constitutes 
confidential (high) vs. public (low) data, in contrast to most 
related work where variables are syntactically labeled with a 
desired security level [28, 45]. The semantic characterization 
allows the same variable or pointer to contain data of different 
security levels at different points in program execution, which 
gives us the needed flexibility of enforcement. The semantic 
characterization also facilitates precise specification of pro¬ 
grams with implicit information flow such as procedure calls 
or (possibly nested) conditionals. 

Our third and technically central contribution is a novel 
verification system, Relational Hoare Type Theory (RHTT), 
that integrates a programming language and a logic into a 
common substrate underlying all of (a)-(c) above. In more 
detail, RHTT provides (a) and (b) by including the type 
theory of the Calculus of Inductive Constructions (CiC) [25, 
Chapter 4], as implemented in the Coq proof assistant. To 
provide for (c), RHTT introduces a new type constructor 
STsec, which classifies side-effectful computations similar 
to Haskell monads [34], except that the STsec monad is 
indexed with a precondition and a postcondition, as in a Hoare 
triple. STsec types separate the imperative from the purely 
functional fragment of the type theory, ensuring soundness of 


their combination. 

RHTT’s preconditions specify constraints on the environ¬ 
ment under which it is safe to run a program, and can 
be used to enforce authentication and authorization policies, 
even when they depend on state. RHTT’s postconditions are 
relational assertions; they specify the behavior of two runs of a 
program [1], The relational formulation directly captures in the 
types the notion of noninterference [18], a prominent semantic 
characterization of confidentiality. Together with higher-order 
type theory, this provides an architecture for uniform treatment 
of all the policies mentioned above. 

For example, we show that the fundamental linguistic ab¬ 
stractions required to specify and implement declassification 
are STsec types, modules and abstract predicates. A module 
can be used to delimit the scope in which data is considered 
public, by hiding the publicity of the data from module chents 
via existential type abstraction [26]. Then declassification 
amounts to breaking the abstraction barrier by an exported 
interface method that reveals this in-module publicity. This is 
orthogonal to revealing the data itself. The latter can always be 
done even without declassification, but the clients will have to 
use such data as if it were confidential. Declassification may 
be unconditional or conditional [7], where the condition might 
be stateful and involve, e.g., authentication. 

In information erasure policies [15, 16] confidential data 
may be released within a delimited scope, provided there is 
a guarantee that such data will be erased upon exit from the 
scope. We show that such policies can be specified using a 
combination of higher-order functions with local state, mod¬ 
ules and abstract predicates. The key facilitating component 
here is that ST sec types may appear in argument positions in 
function types, which is similar to having Hoare logic where 
one can reason about Hoare triples hypothetically wrt. the truth 
of other Hoare triples. A similar combination of features can 
be used to grant a method access to data only if the method 
provably conforms with some desired confidentiality policy. 

Finally, state-dependent information flow and access control 
policies require abstract predicates combined with mutable 
state. This allows expressing security policies that can change 
with time due to state updates [43]. 

Our development of RHTT overcomes a number of techni¬ 
cal challenges. First, for relational reasoning to be applicable 
at all, the type system must give special status to instantiations 
of a program e with high values. The special status is 
needed so that the same postcondition of e can relate e’s 
different instantiations. Our solution is to introduce new typing 
and programming primitives for abstraction and instantiation 
wrt. a number of variables, simultaneously (Section II). This 
illustrates why our type system had to be developed hand- 
in-hand with the associated relational verification logic, as 
each must possess the requisite constructs to facilitate the 
other. The second challenge concerns the semantic treatment 
of allocation and deallocation, pertaining to dynamic data 
structures. Existing techniques [1,6] for modelling allocation 
in the relational security setting cannot cope with deallocation; 
hence the need for two different allocators — one for low and 


another for high addresses (Section III). 

In a companion technical report [29] (TR in the sequel) 
we develop a logic for relational reasoning about RHTT pro¬ 
grams, and a worked out verification of an example program. 
Inference rules of the logic have been verified sound against 
a semantic model, and are formally implemented as lemmas 
in RHTT. The soundness of our program logic, the domain 
theoretic implementation of our semantic model, as well as 
all of our examples, have been fully and formally verified in 
Coq. Additional technical difficulties arise in this process, but 
we elide them here for readability. The interested reader is 
invited to look at our Coq proofs, and the companion TR, 
which are available at http://software.imdea.org/~aleks/rhtt/. 

II. RHTT BY EXAMPLES 

Overview: As suggested by the introduction, this paper 
assumes understanding of the following aspects of type theory: 
(1) Dependent function types, used to specify how the body of 
a function depends on the input arguments. To illustrate, con¬ 
sider the type vector(n), of integer-storing arrays. This type 
is dependent on the size parameter n. A function computing 
the inner product of two vectors can be typed as 

nn:nat. vector(rj) x vector(n) -* nat 

capturing the invariant that that the argument vectors must be 
of equal size. In RHTT, dependent function types naturally 
arise when specifying any kind of program behavior. (2) 
Module systems (including abstract types and predicates), 
for information hiding, and as we show, declassification. (3) 
Inductive types, for specifications of programs that manipulate 
(possibly heterogeneous) data structures such as lists, trees, 
etc. 

To use RHTT in practice, it is further important to be 
familiar with some implementation of type theory (our chosen 
one is Coq [25], but others exist too), as one needs to 
interact with the system to discharge verification conditions. 
Our presentation in this paper does not include such interaction 
aspects, and hence does not assume familiarity with Coq. 

RHTT basics: types, specifications, opaque sealing: To 
begin with, our types must be able to express at least noninter¬ 
ference: that low outputs of a computation are independent of 
high inputs. To illustrate, assume a function f:A 2 —tA 2 , where 
A 2 = A x A. Also, let e.l and e.2 denote resp. the first and the 
second component of the ordered pair e. Then, mathematically, 
f’s first output is independent of f’s second argument iff 

Vzi X2 yi yi- X! = X2^r f(x i, ?/i).l = /fa, yz)A 

In other words, in two runs of /, equal x inputs, lead to equal 
f(x,y)A outputs. This relational statement of independence 
can be viewed as a definition of noninterference in terms 
of / alone [1, 9], without recourse to outside concepts such 
as security lattices [8, 17]. Consequently, inputs and outputs 
related by equality in the two runs of / are considered low 
(x and f(x, y)A above), and the unconstrained values (y and 
f(x,y). 2) are by default considered high. So defined, the 
notions of low and high security are intrinsic to the considered 


specification, rather than to the code itself; one is free to 
consider statements about / in which the inputs and outputs 
take other security levels. 

In RHTT, program specifications are stated using a monadic 
type STsec A (p, q), which classifies heap-manipulating, po¬ 
tentially diverging computations e whose return value has type 
A. e’s precondition p is a predicate over heaps, i.e., function 
of type heap—»prop. The reader can roughly think of prop as 
type bool which in addition to the usual logical operations 
supports quantifiers as well. The precondition selects a set of 
heaps from which e’s execution will be memory-safe (e.g., 
there will be no dangling-pointer dereferences or run-time 
type errors). This automatically provides a mechanism for 
controlling access to heap locations, in a manner identical to 
that of separation logic [35]: e may only access those locations 
that are provably in all the heaps satisfying e’s precondition, 
or that e allocated itself. We will illustrate access control via 
preconditions in subsequent examples (see, e.g., Example 4). 

The postcondition q relates the output values, input heaps 
and output heaps of any two terminating executions of e. Thus 
q has the type A 2 — »heap 2 —»heap 2 —>-prop. The postcondition 
does not apply if one or both of the executions of e are 
diverging. In that respect, our type system is termination 
insensitive [38]. While p controls access to locations x, we 
use q to implement information flow policies about x. This 
is why q is a predicate over two runs. For example, q may 
specify that x is low, so that e may freely propagate x’s value. 
Or x may be high, requiring that all ^-dependent outputs of 
e must be high too. Or x may be high but q may require all 
of e’s final heap to be low, in which case e must deallocate 
or rewrite any portion of its final heap that depends on x. 

RHTT is implemented via shallow-embedding into Coq, 
which it extends with STsec types. In the implementation 
of STsec types in Coq, we rely on the ability of Coq 
modules to perform opaque sealing [19, 22]; that is, hiding 
the implementations of various values within a module, while 
only exposing their types, thus forcing the clients of the 
module to be generic with respect to implementations of the 
module. Moreover, the actual implementations of opaquely- 
sealed functions, types and propositions cannot be recovered 
by clients, because RHTT does not contain constructs for 
pattern-matching (i.e., making observations) on the structures 
of such values. 

We point out that our types can only describe the properties 
of the input and output states of the program (via pre- and 
postconditions), but not of intermediate states. Although this 
is not a significant limitation for a sequential, non-reactive 
language like RHTT, further work in this direction is left for 
future work. 

Syntax, heaps, implicit flow: Consider the following 
program, Pi, adapted from Terauchi and Aiken [44], and 
presented here in a Haskell-like notation. We use side-effecting 
primitives such as write x y, which stores the value y into 
the location x; read x, which returns the contents of x; and 
x <— ei; e2, which sequentially composes ei and e2, binding 
the return value of ei to x. In future examples, we will also 


use alloc x, which returns a fresh memory location initialized 
with x; and dealloc x, which deallocates the location x from 
the heap. Additionally, we use do to delimit the scope of the 
side-effectful computations. Our actual syntax implemented in 
Coq differs somewhat from the one here in the treatment of 
variable binding, an issue we ignore for the time being but to 
which we return in Section III. Further, we freely use all the 
constructors inherited from CiC and Coq, such as for example, 
functions (fun), and dependent function type constructor (II). 

Pi = fun x y z lo hi: ptr. 

do (write z 1; b 4— read hi; 

if b then write x 1 else ( w <— read z; write x w); 
u t— read x; v «- read y; 
write lo ( u + ( v mod 10))) 

Pointers x,y,z,lo store integers, and hi stores a boolean. The 
policy is: contents of lo and y are low at program input and 
output, while contents of x,z, hi are high. P| satisfies the 
policy because: (1) the value of y is not modified, and (2) the 
value of lo is modified to store the sum of the contents of x 
and the contents of y modulo 10, but this sum is independent 
of high data: at the time of writing lo, x has been rewritten 
by 1 in both branches of the conditional. Thus, Pi can be 
ascribed the following dependent type, U. 

U = na; yz lo hi: ptr. STsec unit 

(fun i.3u v vu c:nat. 6:bool. j:heap. 

i = xv-tu • y\-¥v • zv-tw • hi\-vb • lov-¥ c • j, 
fun rr it mm. 

(ii. 1 lo = ii. 2 lo) —> (ii. 1 y = ii. 2 y) —y 
(mm. 1 lo = mm. 2 lo A mm. 1 y = mm. 2 y)) 

The precondition states that Pi must start in an initial heap i 
containing the five pointers x, y, z, lo, hi, with appropriately- 
typed contents. The heap i may be larger still; this is stated 
by existentially quantifying over the heap variable j. Heaps 
are (finite) maps from pointers to values; x i-» u is a singleton 
heap containing only the location x storing value u; and • is 
disjoint heap union. The precondition insists that i be a disjoint 
union of smaller singleton heaps; hence there be no aliasing 
between the five pointers. The postcondition binds over three 
variables rr:unit 2 , ii,mm: heap 2 which are, respectively, the 
pair of return values, the pair of initial heaps and the pair of 
ending heaps for the two runs of Pi. The postcondition states 
that if the contents of lo and y in the two initial heaps are 
equal (hence low), then they are low in the output heaps too. 

Other types for Pi are possible too. For example, we may 
specify that only the last digit of y is low, by replacing ii.l y 
with (ii.l y) mod 10 in the postcondition, and similarly with 
ii. 2, mm. 1 and mm.2. Or, the postcondition may state that 
the contents of x and z are low at the end of Pi, though 
not at the beginning. RHTT (like [1]) can deem arbitrary 
expressions as low, even though they may have high subparts. 
The only requirement is that the values of the expressions 
in two runs are the same. Because we are considering full 
functional verification, which STsec type a program should 
have is a matter of programmer’s choice. The system merely 


issues a proof obligation that the desired type is indeed valid, 
to be discharged interactively, using the logic we outline in the 
TR (Section 4). This proof obligation may not only be about 
security but also may concern full functional correctness. 

Opaque sealing: The ascription of ST sec types in RHTT 
is opaque, as mentioned earlier in this section. Even if program 
execution makes more values low, this knowledge cannot be 
utilized by clients if it is not exposed in the postcondition. For 
example, using Pi’s type U, program 

Pi = fun x y z lo hi. do (Pixy z lo hi ; t 4- read x\ return t), 

cannot be given a type in which t is low, because the 
postcondition in U does not expose the property that x is 
low at the end of Pi. 

Local contexts: While the ST sec type of Pi classifies the 
security of the contents of x, y, z, lo, hi, it cannot classify the 
pointer addresses themselves, as the latter requires discerning 
the address names in the two different runs (e.g., x.l and 
x.2). We therefore extend the STsec constructor with a local 
context, which is a list of types of the variables we consider 
local to the computation. For example, the type for Pi in which 
the five pointer addresses are high, even though the contents 
of lo and y are low, can be written as follows, using the list 
[ptr, ptr, ptr, ptr, ptr] as the local context. 

STsec [ptr, ptr, ptr, ptr, ptr] unit 
(fun x y z lo hi:ptr. i:heap. 

Mu v w c:nat. 6:bool. j:heap. 

i = u • yt-^>-v • zt-> w • hii-^- b • lot-^ c • j, 
fun xx yy zz llo hhi:ptr 2 . rr:unit 2 . ii mm: heap 2 . 
it. 1 llo. 1 = ii.2 llo .2 —» ii. 1 yy. 1 = ii.2 yy.2 -t 
mm. 1 llo. 1 = mm.2 llo.2 A mm.l yy. 1 = mm.2 yy. 2) 
The type of the precondition (and similarly for postconditions) 
now changes to ptr 5 —»heap—»prop, so that we can bind 
additional names for the pointers x, y, ... in the precondition, 
and pairs of pointers xx, yy, ... in the postcondition. The 
program syntax changes too, as the local variables now have to 
be bound within the scope of do. In other words, our program 
now looks like P3 = do (fun x y z lo hi. write z 1;...). 

Remark 1. Ordinary function arguments, corresponding to the 
—► and II-types, can be viewed as a special kind of STsec-local 
arguments, where the security level is low by default. Indeed, 
any function f:Ux:A. STsec T (p x, q x) can be transformed 
into 

do (fun x 71... 7„./ x 71 ... 7„) : 

STsec (4::r) B 
(fun x 71... 7„. p x 71... 7 n , 
fun xx 771.. -77n yy ii mm. 

xx.l = xx.2 —> q xx 771... yy ii mm) 

Here, the variables 71,..., j n are typed with types from the 
local context F, and the postcondition explicitly declares x to 
be low, by inserting the hypothesis m:.l = a::r.2. To summarize, 
function arguments are always low, whereas variables in local 
contexts may be low, high, or subject to a more precise security 
specification, depending on the postcondition. 


Example 1 (Nested conditionals). The following program is 
adapted from Simonet [40]. It uses low arguments a, b, c, u, v, 
and a high argument x which is declared in the local context 
but is unrestricted by the postcondition. It nests two condition¬ 
als to compute the final result, but the result is independent 
of x, and hence is low. Owing to the non-trivial implicit 
control flow, however, most security type systems will not 
be able to establish this independence and typecheck the 
example accordingly. Simonet’s type system for sum types can 
typecheck the example using types annotated with matrices 
containing security levels. In contrast, in RHTT the type can 
precisely describe the final result, y, as a function of the inputs: 
y = (a = c) || (b = c) || u || v. Clearly y does not depend on 
x and we prove that y is low by proving that yy.l = yy.2 in 
the postcondition. 

Pa : n<j b cu u:bool. STsec [bool] bool 
(fun x i. True, 

fun xx yy ii mm. yy.l = yy. 2 A mm = ii A 
yy.l = {a=c ) || (b = c) || u|| v) = 
fun ab cuv. 

do(fun x.t 4— if u then 

if x then return a else return b 
else 

if v then return a else return c; 
return ((t = a) || (i = &))) 

Example 2 (Access control through abstraction). What if we 
want to allow read access, but not write access to some data 
(or vice-versa), or that access should be made conditional 
upon successful authentication? To enforce this kind of access 
control, we employ the standard abstraction mechanisms of 
type theory, such as abstract types, predicates and modules. 
The data to be protected can be hidden behind module 
boundaries, so that it can be accessed only via dedicated 
methods that enforce access control. For example, let Alice be 
a module storing some integer data, say salary, whose integrity 
should be enforced: Alice allows the salary to be readable 
globally, but only Alice herself can update it, to keep the 
value coherent with promotions at work. Thus, she exports 
unconstrained functions for creating new instances and for 
reading the salary, but the function for writing requires a check 
against a password that is also stored locally. The signature, 
AliceSig in Figure 1, presents the specifications that Alice 
wants to export, and a possible module implementing AliceSig 
by keeping two local pointers - one for the salary, one for 
the password - is given in Figure 2. Referring to Figure 2, 
the method new takes a nat salary and a string password, 
and generates a new instance of Alice, initialized with this 
data; read_salary takes a local-context argument representing 
Alice, and returns her current salary; write_salary takes a new 
salary, a password, and an a I ice argument in the local context, 
and updates the salary only if the supplied password matches 
the password stored in the a I ice argument. Referring back to 
Figure 1, AliceSig specifies an abstract type a I ice, abstract 
predicates sshape and shape, a relation, srefl, between shape 
and sshape, and the types of the methods. Although these 


alice : Type 

sshape : alice 2 —> nat 2 —> string 2 —> heap 2 —> prop 
shape = fun asp h. sshape (a, a) ( s,s ) ( p,p ) (h, h) 
srefl : Vaa ss pp ii. sshape aa ss pp ii —> 

shape aa. 1 ss. 1 pp. 1 ii.l A shape aa. 2 ss. 2 pp. 2 ii. 2 
new : nat ->■ string ->■ STsec nil alice 
(fun A True, 
fun aa ii mm. 

fiss pp hh. mm = ii •• hh A sshape aa ss pp hh) 
read_salary : STsec [alice] nat 

(fun a i.3s p j h. i = j • h A shape a s p j, 
fun aa yy ii mm.Vss pp jj hh. 

ii = jj •• hh —> sshape aa ss pp jj —»• 
mm = ii Ayy = ss) 

write_salary : nat —► string —> STsec [alice] unit 
(fun a i.3s p j h. i = j • h A shape a s p j, 
fun aa qq yy ii mm.Vss pp jj hh. 
ii = jj •• hh —► sshape aa ss pp jj —► 

3jj' ss'. mm = jj' •• hh A sshape aa ss' pp jj') 

Fig. 1. AliceSig: access control via abstract predicates. 

type alice = ptr x ptr 
salary (a : alice) = a.l 
passwd (a : alice) = a.2 

sshape (aa : alice 2 ) (ss : nat 2 ) (pp : string 2 ) (ii : heap 2 ) = 

11.1 = salary aa.li-Ass.l • passwd aa.l^-pp.l A 

11. 2 = salary aa. 21-»- ss. 2 • passwd aa. 21-» pp. 2 A 
ss.l = ss .2 A pp. 1 = pp .2 

new sj> = do (x <— alloc s-,y<— alloc p; return ( x , y)) 
read_salary = do (fun a. read (salary a)) 
write_salary s p = 

do (fun a.x <— read (passwd a); 

if x = p then write (salary a) s else return ()) 

Fig. 2. Implementation of AliceSig. 

figures may look complicated, the reader should bear in mind 
that they are intended for full functional verification. Also, the 
definitions of the various abstract predicates and types such as 
sshape, shape and alice, will be hidden from the clients, and 
do not contribute to the complexity. 

The sshape predicate is a relational invariant of the module’s 
local state (i.e., invariant over two runs). It is parametrized 
over pairs of alices, nat salaries, string passwords, and heaps 
that are current during execution. The parametrization by all 
these values captures that different instances of Alice that 
may be allocated at run time all have different local states, 
which can potentially store different salaries and passwords. 
If we were not interested in tracking the changes to salaries 
and passwords, but only in restricting write access, then these 
can be omitted from sshape, resulting in fewer quantifiers and 
hence simpler STsec types for the methods. 

For use in preconditions for access control, we employ the 
non-relational variant shape which is a diagonal of sshape, as 
constrained by srefl. Recall that a computation in RHTT can 


access locations only in those heaps that provably satisfy its 
precondition. Correspondingly, a method that wants to access 
Alice’s local state, has to describe the desired parts of that state 
in its own precondition. This is why AliceSig keeps sshape and 
shape abstract. The abstraction hides the layout of Alice’s local 
state from the clients, thus preventing them from describing 
the layout in their preconditions and forcing them to access 
Alice’s local state exclusively via the exported methods. Apart 
from giving code for the methods, the implementation also 
provides a proof of srefl (elided here, but present in the Coq 
scripts). 

The STsec types in Alice’s methods describe several ad¬ 
ditional properties. For example, that the local state of each 
instance of Alice is disjoint from that of another instance. For 
new, this is achieved by stating that the pair of ending heaps 
mm extends the initial ones ii by newly allocated sections hh 
(mm = ii •• hh). Here •• generalizes the disjointness operator 
• to pairs of heaps, that is, (ii, if) •• (hi, h 2 ) = (ii • h-\. i 2 • h 2 ). 
For read_salary, we allow that the state in which the function 
executes be larger than the module’s local state by allowing 
ii = jj •• hh where jj names the local state and hh is the 
potential global part. For write_salary we require that the 
global part, hh, remain invariant, but the local part may be 
changed by storing the new salary. 

Finally, the specifications expose that read_salary does not 
change Alice’s local state (mm = ii in the postcondition). On 
the other hand, write_salary may change the salary field, but 
not the password field, as the sshape predicate changes from 
using the salary ss to using ss', but pp persists. 

Notice that the salary and password arguments in new and 
write_salary are ordinary function arguments, whereas alice is 
in the local context of STsec in read_salary and write_salary. 
Thus, within the scope of Alice’s methods, the salary and the 
password are low (c.f. Remark 1) whereas the alice argument 
is high because it is unconstrained by the methods’ pre- and 
postconditions. Of course, as far as clients of AliceSig are 
concerned, all three of these are high: the abstraction over 
sshape hides all relations between the stored values. 

Example 3 (Declassification). One consequence of making 
salary and password internally low is that whenever a new in¬ 
stance of Alice is allocated, or a salary of an existing instance 
is changed, the salary and password have to be computed 
only out of low arguments - it is not possible for Alice 
to store confidential data into her local fields. Additionally, 
the specifications of new and write_salary must hide that the 
stored salary and password are equal to the supplied ones. The 
latter are internally low, while the former are to be externally 
high. The hiding is achieved by existential quantification over 
ss and pp in the postcondition of new, and over ss' in the 
postcondition of write_salary. 

Alice can use the internal knowledge that salary and pass¬ 
word are low, to implement and export an additional function 
which declassifies her salary - that is, reveals the internal 
knowledge that the salary is low. This declassification can be 
based on arbitrary conditions - say, it is only granted if a 


rreadable : alice 2 —► heap 2 —> prop 
readable = fun a ft. rreadable (a, a) (ft, ft) 
rrefl : Vaa ii. rreadable aa ii —► 

readable aa. 1 ii. 1 A readable aa .2 ii .2 
grant : STsec [alice] unit 

(fun a i. 3s p j ft. i = j • ft A shape a s p j, 
fun aa yy ii mm.\/ss pp jj ftft. 

ii = jj •• ftft —> sshape aa ss pp jj —> 

3jj'. mm = jj' •• ftft A sshape aa ss pp jj 1 A 
rreadable aa jj') 
revoke : STsec [alice] unit 
(fun a i.3s p j ft. 

i = j • h A shape a s p j A readable a j , 
fun aa yy ii mm.\/ss pp jj ftft. 

ii = jj •• ftft -t sshape aa ss pp jj ->■ 

Bjj'. mm = jj' •• ftft A sshape aa ss pp jj') 

read_salary : STsec [alice] nat 
(fun a i.3s p j ft. 

i = j • h A shape a s p j A readable a j, 
fun aa yy ii mm.Vss pp jj ftft. 

M = jj •• ftft —► sshape aa ss pp jj —> 
mm = ii Ayy = ss) 

Fig. 3. Extension of AliceSig with state-based read access, 
correct password has been supplied. 

declassify : IIp:string. STsec [alice] bool 

(fun a i.3s q j h.i = j • ft A shape a s q j, 
fun aa yy ii mm.\/ss qq jj ftft. 

H = jj •• ftft -t sshape aa ss qq jj 

9 jj'. mm = jj' •• ftft A sshape aa ss qq jj' A 
yy -1 = ra-2 Ayy = {p= qq. 1, p = ?g.2) A 
t/p.l —)• ss.l = ss.2) = 

fun p.do (fun a.x <— read (passwd a); return (p = x)) 
The code of declassify checks if the supplied password 
equals the stored one, and returns the corresponding boolean, 
declassify does not return the value of the salary; for that, 
one has to use read_salary, but the specification of declassify 
shows that the salary is low if declassify returned true 
{yy.l —¥ ss.l = ss.2). This is possible because the low-status 
of the salary has been hardwired into the implementation of 
sshape, and Alice can reveal it at will. 

Example 4 (State-based policies). Alice can implement poli¬ 
cies that change depending on her local state. For example, 
she may control the granting of read access with functions 
grant and revoke, as specified in Figure 3. These enable and 
disable reading by, respectively, adding and removing a new 
abstract predicate - rreadable - from the knowledge exposed 
about Alice’s local state. Typically, such functions require 
authentication, but for simplicity, we forgo that aspect. The 
postcondition of grant exposes that the newly obtained state 
jj' is readable, while revoke omits this property, thus revoking 
the read access. To associate the predicate with reading, the 
specification of read_salary has to require a proof of readable. 

The signature keeps rreadable abstract, so that the only 


bbshape : bob 2 —»G 2 —»heap 2 —»prop 

bshape = fun 6 ft t. bbshape (6,6) (ft, ft) (t, t) 

brefl : ... (* similar to srefl *) 

epre (a : alice) (6 : bob) (j i : heap) = 

3s p k t h.i = j • t • h A shape a s p j A bshape 6 ft t 
epost aa 66 jj yy ii mm = 

Vss pp ftft tt ftft. ii = jj •• tt •• ftft —> 

sshape aa ss pp jj bbshape 66 ftft tt —> 

3jj' tt'. mm = jj' •• tt' •• ftft A sshape aa ss pp jj' A 
bbshape 66 (bcmp fcfc.l, bcmp ftft.2) tt' A 
(tt. 1 = it.2 -> tt'. 1 = tt'.2) 

Fig. 4. Some definitions for conditional access and erasure policies. 

way readable can be derived is if rreadable has been placed 
into the proof context by a previous call to grant, without 
an intervening revoke. The signature can be implemented by 
extending Alice’s state with an additional boolean pointer that 
is set and reset by grant and revoke: rreadable is in force 
once the boolean is set true. Our Coq scripts provide several 
different implementations of this interface. 

Example 5 (Conditional access and erasure policies). Suppose 
Alice wants to download a program from Bob for computing 
tax returns. Alice is willing to let Bob access her local state 
and read her salary directly using read_salary, but wants to 
prevent Bob from stealing her secret by copying it into his 
own local state. Alice may insist that Bob not keep any local 
state, or that he deallocate all of it before termination. But this 
is too restrictive, for Bob may want to keep in his local state 
a count of how many times his program has executed. Such 
local state should be allowed to escape the function call as it is 
independent of Alice’s salary. In RHTT, Alice can formulate 
such a permissive policy. 

We start the description of Alice’s specification by as¬ 
suming that bob is an abstract type representing Bob’s lo¬ 
cal state (usually implemented as the set of root pointers 
for Bob’s local state). G is another abstract type repre¬ 
senting the values that Bob keeps in his local state. For 
example, if Bob wants to count how many times his pro¬ 
gram has been invoked, then G = nat. Further, we assume 
bbshape:bob 2 — >G 2 — »heap 2 —»prop is an abstract predicate 
describing Bob’s local state, and bcmp:G— >G describes how 
Bob’s local state changes within one function call. In the 
counting example, bcmp will be the program Bob needs to run 
over both Alice’s and Bob’s local heap. The initial heaps i for 
his program can therefore be split in three ways: j belonging 
to Alice, t belonging to Bob, and the remainder ft that is 
untouched. Predicate epre in Figure 4 describes this situation. 
On the other hand, epost states that Bob’s local state tt' at 
the end stores the correct statistics (bcmp of ftft. 1 and ftft.2), 
and if Bob’s initial local state tt is assumed low, then tt' is 
low as well. In other words, Bob did not copy into tt' any of 
the high values that he may have read from Alice. A program 
that requests read access to Alice’s local store, and respects 


the described policy has the type 

T = STsec [alice, bob] nat 

(fun a 6 i.3j. readable a j A epre a b j i, 
fun aa bb yy ii mm.Vjj. 

rreadable aa jj ->■ epost aa bb jj yy ii mm) 
Alice now wants to ratify programs with type T by granting 
them read access to her salary. She can do so by exporting 
from her module a function ratify which removes readable 
from T, much like the grant program would do. After that, 
Bob’s program can execute without needing special reading 
privileges. In this respect, ratify is a higher-order function 
because in its type, STsec appears in a negative (argument) 
position, ratify can be said to implement a conditional access 
policy, because it grants access only after Bob supphes a proof 
that his program satisfies the type T, i.e., the program does 
not leak Alice’s salary. 

ratify : T -> 

STsec [alice, bob] nat 

(fun a b f.3j.epre a b j i, 
fun aa bb yy ii mm. 

Vjj.e post aa bb jj yy ii mm) = 
fun e : T. do (fun a b.e a b) 

This specification can be instantiated in several ways, 
by choosing different values for bob, G, bbshape and 
bcmp. For example, if bob = ptr, G = nat, bcmp = succ and 
bbshape bb kk tt = (66.1=66.1 i-t- kk.l A tt.2 = bb.2\-^ kk.2) 
then Bob’s program keeps a single pointer whose content is 
incremented by 1 after every execution. 

Bob’s program which computes the tax of 24% of Al¬ 
ice’s salary, while also keeping its invocation count, can be 
implemented and then immediately ratified by the following 
function call. Notice that by the type of ratify, the return 
value of Bob’s program is high as there is no requirement 
yy.l = yy.2 in epost. Hence, the fact that this value is a 
function of Alice’s salary, is not a security leak. 

ratify (do (fun ccalice 6 :bob. 

x 4- read_salary a; k 4— read 6 ; 
write b (k + 1); return (x * 24%))) 

Suppose Bob keeps the count with two nat pointers, whose 
contents p and q are both increased at every call, so that 
the overall count is the difference between the two. This is 
represented by taking bob = ptr x ptr (one ptr for p and one 
for q), G = nat, bcmp = succ and bbshape bb kk tt is 

3 pp qqmat 2 . tt.l = fst (66.1) t-^-pp.l • snd (66.1) i-»- qq.l A 
tt. 2 = fst (66.2) i-^pp.2 • snd (66.2) qq.2 A 
kk = (pp. 1 — qq.l, pp.2 — qq.2)) 

Bob’s program can read Alice’s salary, then increment p and 
q by amount of the salary, and additionally, increment p by 
1. In terms of required specifications for Bob’s local state, 
the program still keeps the invocation count. However, the 
program is actually steahng Alice’s salary, because the salary 
can be inferred by deducting the old value of q from the new 


one. Bob will fail to get such a program ratified by Alice, if 
he calls ratify with the argument 

do (fun malice 6 :bob. x 4- read_salary a; 
p 4— read (fst 6 ); g 4— read (snd 6 ); 
write (fst 6 ) (p + z-l-l); write (snd 6 ) (q + x)\ 
return (x * 24%)) 

ratify forces Bob to prove that his ending state is low 
(tt'. 1 = tt!.2) as defined in epost, but this is not provable if 
tt! stores Alice’s salary x. Indeed, as x is high. Bob lacks 
the information that x is equal in the two runs, so he cannot 
prove that his pointers store equal values in two runs. For 
ratification. Bob will have to erase Alice’s salary from his 
state, perhaps by mutating his pointers to store p +1 and 
q instead of p + x + l and q + x. ratify may thus be said 
to implement an erasure policy, similar to those of Chong 
and Myers [15, 16]. Alternatively, Bob may try to declassify 
Alice’s salary, using the function from Example 2, but then he 
has to provide the correct 

III. Typing rules 

Each command of the stateful fragment of RHTT comes 
with a dependent STsec type that captures the command’s 
specification using pre- and post-conditions. We start our 
description with the types of the basic commands; descriptions 
of the other commands appear later in the section. 

return : STsec [A] A 

(fun x 6 . True, 

fun xx yy ii mm. mm = ii Ayy = xx) 
read : STsec [ptr] A 

(fun £ i. 3/i:heap v: A. i = £ i-» v • h, 
fun ££ yy ii mm. mm = ii A 
Vhh vv. ii = (££.l !-► vv.l,££.2>-> m.2) •• hh —» 
yy = vv) 

write : STsec [ptr, A] unit 

(fun £ v i. 3h B: type w:B. i = £t-t w • h, 
fun ££ vv yy ii mm. 

\/hh B\ B‘2 w-\ :B[ »2: B 2 . 
ii = (£1.1 !->■ wi, ££.2 h-j- w 2 ) •• hh —>■ 
mm = (££. 1^ vv.l,££.2^ vv.2) •• hh) 
dealloc : STsec [ptr] unit 

(fun £ i. 3h B: type w:B. i = £\-tw • h, 
fun££ yy ii mm. 

Vhh B 1 B-2 w-|: B t w 2 :B 2 . 
ii = (£l.l\-+ w\,£t.2\-+ W2) •• hh —> 
mm = hh) 

return immediately terminates with the value that was sup¬ 
plied as a local argument. Its STsec constructor records the 
argument type in the local context, and the type of the 
returned value (here, both types are A). The precondition 
states that return can execute in any heap, as it performs 
no heap operations. The postcondition states that return does 
not change the input heaps (mm = ii) and passes the input 
argument to the output (yy = xx). The precondition of read 
write and dealloc all require that the initial heaps contain at 


least the pointer £ to be read from, written to or deallocated. 
In the case of read, the contents of the pointer must have the 
expected type A. For write and dealloc, this type is irrelevant 
and is hence existentially quantified. The postconditions of all 
three commands explicitly describe the layout of the new heap 
and, in particular, state that parts of the input heaps that are 
disjoint from £ (hh above) remain invariant. 

Allocation presents the following challenge. If under a high 
guard, a pointer is allocated in one branch of a conditional, 
but not in the other, this may constitute a leak of the high 
guard, if the pointer itself is of low security. Such “unmatched” 
allocations should therefore always produce high pointers. 
This is why we provide two allocation primitives: lalloc for 
allocating low pointer addresses, and alloc, for allocating high 
ones. 

lalloc : STsec [A] ptr 

(fun v i. True, fun vv yy ii mm. 

mm = (yy. 1 vv. 1, yy.2 >->• vv.2 ) •• ii A 

(HA = H- 2 -A yy. 1 = yy. 2 A mm.l = mm.2)) 

alloc : STsec [A] ptr 

(fun v i. True, fun vv yy ii mm. 

mm = (yy.l i-»- vv.l, yy.2 v-tvv.2) •• ii A 
even yy. 1 A even yy.2) 

Both commands take a local argument v.A, and return a 
fresh pointer initialized with v. The freshness is captured in 
the postcondition by demanding that the initial heaps ii be 
disjoint from the returned pointers yy in the equation for 
the ending heaps mm. However, alloc chooses the returned 
location non-deterministically, while lalloc is deterministic, 
that is, it returns equal (and hence low) pointers, when invoked 
under appropriate conditions. We make the two allocators 
operate on disjoint pools of locations: alloc always returns 
an even pointer (albeit, a randomly chosen one), while lalloc 
returns the next unallocated odd pointer. Here we rely on the 
property that type ptr is isomorphic to nat in our model. 

Definition 1. Heaps h\ and h% are low-equivalent, written 
hi = / 12 , iff their domains contain the same odd pointers. The 
content of the pointers is irrelevant. 

The postconditions of lalloc and alloc further capture the 
behavior of the two commands with respect to the = relation. 
In the case of lalloc, we expose that if invoked in low- 
equivalent input heaps (ii. 1 = ii.2 ), the command returns 
equal pointers (yy. 1 = yy.2), and low-equivalent output heaps 
(mm.l = mm.2). In the case of alloc, we expose the evenness 
of yy.l and yy.2, and provide a number of lemmas, that can 
be used to relate evenness with =. For example, the lemma 

Va::ptr. even x —>• (x i->- v • h\ = hf) o (h\ = ha) 

when iterated, can show that low equivalence of hi and /i 2 
is preserved after arbitrary number of high allocations. Other 
related lemmas are present in our Coq scripts. 

Example 6 (The need for both allocators). The following 
program can be given a type in which the returned pointer 


y is low, no matter what the boolean h is. 

do (fun h. if h then y «— lalloc 2 ; return y else 

x <— alloc 1 ; y «- lalloc 2 ; dealloc x\ return y) : 

STsec [bool] ptr 
(fun h i.True, 

fun hh yy ii mm. mm = ii •• ( yy.l ^ 2, yy.2 1 —2) A 
(ii.l = ii.2 -> yy.l = yy.2)) 

The program does not typecheck if the high allocation of 
x is replaced by lalloc. In that case, it is possible that the 
two executions of the program select different branches of 
the conditional (depending on h). If we started with low- 
equivalent heaps i\ = ia, then at the point of allocation of y, the 
heaps will not be low equivalent anymore, since one of them 
has been extended with an odd location x, while the other has 
not. Thus, we cannot conclude that the returned pointer is low 
(yyA = yy.2). 

Remark 2. Deterministic allocation forces ST sec to use large- 
footprint specifications, whereby specifications describe the 
full heaps in which commands operate. This is in contrast to 
separation logic, where specifications describe only those heap 
parts that commands touch, and implicitly assume invariance 
of the remaining heap. The latter style is more succinct, 
but cannot support deterministic allocation [47]. With large 
footprints, we can specify lalloc (specifically, the antecedent 
ii.l = ii.2 in the postcondition), but the invariance of un¬ 
touched parts of heaps has to be stated explicitly for every 
program, as witnessed by the quantification over hh in the 
postconditions of write and dealloc. Note that the concrete 
layouts of untouched parts of heaps do not need to appear 
in the specifications — thus alleviating concerns of scalability 
of specifications. Moreover, the overhead between large and 
small footprint specifications is constant, as we discuss in 
Section 6 of the TR. The two styles also lead to similar proofs. 
What matters in proofs is the ability to effectively reason about 
heap disjointness, and we can do that equally well in both 
styles by relying on the operator • [32], 

Another way of treating allocation in the relational setting 
is to model its non-determinism by means of partial bijections 
between pointers [1]. Then one can avoid using two different 
allocators, albeit at a price of increasing the complexity of rea¬ 
soning. Such proposals, however, only work in the absence of 
deallocation. For example, the definition of noninterference of 
Amtoft et al. [1] allows that the input heaps to the computation 
are related by some bijection between pointers, and requires 
that the ending heaps are also related by a bijection. However, 
the ending bijection has to be an extension of the initial one. 
Obviously, such a definition cannot support deallocation, as 
deallocation produces smaller, not larger heaps. Alternatively, 
one can omit the extension requirement; but that leads to 
counterexamples which satisfy the weakened requirement even 
though they actually leak information. 

We proceed to describe our constructor for sequential com¬ 
position, but first we need some notational conventions. Let F 
be a list of types. We denote by F the product of all the types 


in T, e.g., nil = unit and [A,B, C ] = AxBxC. We further 

conflate the function types F —>T and Ti—^F 2 —>- >T, and 

their corresponding terms. For example, we freely interchange 
fun 7: [A, B, C]..., or fun 7... if the types are clear from the 
context, with fun x:A y:B z:C .... Similarly, we interchange 
e ( x , y, z ) with e x y z. We hope that no confusion arises 
due to this abuse of notation; all of our exposition has been 
checked in Coq, where the notation is formally resolved. 

For sequential composition ei; e 2 , let ei: STsec T A (77, q{) 
and e 2 : STsec (A::r) B (p 2 , q 2 ). Then ei; e 2 first executes ei, 
passing the returned value as the first local argument to e 2 . 
Assuming 7:r and 77:F , the STsec type for e\ \ e 2 is 

STsec T B 
(fun 7 i.pi 7 iA 

Vy m.qi (7,7) (y,y) (i, i)(m, m) -> p 2 (y, 7) m, 
fun 77 yy ii mm. 

3vv.A 2 . hh:heap 2 . <7 77 vv ii hh A 

q 2 ((to. 1,77.I), (vv.2, 77.2)) yy hh mm) 

In English, the precondition requires e-\ to be safe in the initial 
heap of the sequential composition, and that any value y and 
heap m obtained as output of e\ - and which thus satisfy ei’s 
“squared” postcondition - make e 2 safe. The postcondition 
states that intermediate values vv and heaps hh exist, obtained 
after running e\ but before running e 2 . 

As ei’s output is bound in the local context of e 2 , we cannot 
treat this output as an ordinary functional variable, despite 
our suggestive notation in Section II. Indeed, as discussed 
previously in Section II, ordinary variables are always low, 
whereas the ones in the local context may be high, depending 
on the specification. Thus, we must rely on variable-free 
representation via combinators, as described next. 

Our first combinator is for changing the local context of an 
STsec type. Given r 1 ,r 2 ,/:Fi—kT 2 , and e:STsec T 2 A (p, q), 
we can instantiate the local variables of e according to /, to 
produce a computation with context Fi. 

e @ / : STsec F, B 

(fun 7 .p (/ 7),fun 77 .q (/ 77.I,/ 77.2)) 

We denote by e @0 7 the special instance of @, when Fi = nil 
and hence, / is isomorphic to a tuple 7:T 2 . We refer to e in 
e @ / or e @0 7 as the head of the instantiation, and to / as 
the explicit substitution. 

Example 7. In Example 2, we implemented declassify as 
fun p. do (fun a. x £- read (passwd a); return (p = a;)).The ac¬ 
tual implementation using combinators is 

fun p:string. do (read @ (fun a. passwd a); 

return @ (fun x a. (p = x))) 

Programs thus become lists of commands instantiated with 
explicit substitutions, where the domains of substitutions grow 
with each command to provide names for the results of 
previous commands. In the above example, the domain of the 
substitution for read includes only the variable malice, but the 
substitution for return also includes a;:string, which names the 


result of the previous read (Alice’s stored password). Similarly, 
the functions new and read_salary are reimplemented as 

new s p = do (alloc @0 s; alloc @ (fun x.p); 

return @ (fun y x. (x, y ))) 
read_salary = do (read @ (fun a. salary a)) 

To set the stage for discussing the combinator cond for 
conditionals we first consider the predicates safe and verify2. 
The former says that an expression e : STSec nil (p, q) is safe 
to execute in any heap i satisfying precondition p, and is 
defined as safe ei = pi. The latter formalizes when it is 
that executions over two programs, e\ , e 2 result in heaps 
and values that satisfy a postcondition q. Although we have 
been concerned thus far with two runs of the same pro¬ 
gram, the above escalation becomes necessary when treating 
a conditional under a high guard because in two runs of the 
conditional different branches may be executed. Assuming 
ei :STsecnilA(n,fi) and e 2 : STsec nil A (r 2 , f 2 ), a pair of 
input heaps ii, and a predicate q: A 2 — »heap 2 —»prop, we define 

verify2 ii e\ e 2 q = 

Myy.A 2 . mm: heap 2 . 

(ii. 1, yy.1, mm.l) £ runs_of e\ —> 

(ii. 2, yy. 2, mm. 2) £ runs_of e 2 —r q yy mm 

Here runs_of (defined in the TR) coerces programs into 
relations between input heaps, output values and output heaps. 
It is a useful intuition to regard verify2 as a relational variant 
of a Hoare style specification, with programs e\ and e 2 , and 
postcondition q, except that the precondition has been replaced 
with concrete heaps ii. 1 and ii. 2. 

Given programs e,:STsec Y A (pi,qi) for i=l, 2, corre¬ 
sponding to branches of a conditional, and a boolean guard 
6:r—»bool (here parametrized over a context), which type 
should we ascribe to the conditional? We would like to be 
precise, and ascribe the weakest precondition sufficient for the 
safety, and the strongest postcondition sound wrt. the expected 
semantics. Unfortunately, computing that postcondition seems 
impossible in the case when the boolean guard is high. Indeed, 
we know that 17 (resp. q 2 ) relates the output heaps if both 
runs of the conditional chose the same branch e-\ (resp. e 2 ), 
but nothing can be said if the branches chosen in the two 
runs are different. Since the principal specification cannot be 
computed, the best we can do is ask the programmer for the 
desired precondition p and postcondition q, and emit proof 
obligations for checking that (p, q) is valid for the conditional. 

cond : IlferT—»bool. 

IIei:STsec F A (p 1: gi). IIe 2 :STsec T A (p 2 ,q 2 ). 

D\ (b, ei, e 2 ) -4 D 2 (b, e 1} e 2 ) ->■ STsec Y A (p, q). 

Here Di captures the safety of the conditional, and D 2 the 




Hoare-style correctness. 

Di(b, ei, e 2 ) = V 7 i.p 7 i —> 

safe (if b 7 then e\ @ 0 7 else e 2 @ 07 ) * 

D 2 {b, ei, e 2 ) = 

V 77 m. p 77-1 M.l —► p 77.2 m.2 —>• 

verify2 ii (if b 77 .I thenei @0 77-1 else e 2 @0 77 - 1 ) 
(if b 77.2 thenei @0 77-2 else e 2 @0 77 - 2 ) 
(fun yy mm. q 77 yy ii mm) 

The definitions of £>1 and D 2 make use of the purely- 
functional conditional if to define when each of the branches is 
taken. In this paper, we conflate cond and if and use if for both. 
Note that, in contrast to other relational Hoare logics [9, 46], 
we do not restrict the reasoning to only the situation where the 
same branch of the conditional is taken in both runs; nor do 
we need side conditions, as in Amtoft et al. [1], that prohibit 
updates of low variables under a high guard (which would 
prevent verification of Pi in Section II). 

Example 8. The function write_salary from Example 2 is im¬ 
plemented with combinators (omitting annotations and proofs) 
as follows. Notice that the guard of the conditional is a term 
with a local context consisting of a:alice and x:string. 

write_salary s p = 

do (read @ (fun a. passwd a); 
if (fun x a.x = p) then 

write @ (fun x a. (salary a, s)) 
else return @ (fun x a. ())) 

A development similar to the one for cond can also be 
carried out for the combinator do and appears in the TR. 
We justify the soundness of our type system by building a 
denotational model for STsec types. This development is fully 
carried out as a shallow embedding in CiC, and we have 
formalized it in Coq. The model, briefly described in our TR, 
is based on predicate transformers. We also show in our Coq 
scripts that STsec T A (p.q) is a complete partial order, thus, 
supporting a combinator fix for least fixed points of continuous 
functions between monadic types. 

IV. Linked data structures 

In this section we develop a small library for finked lists 
to illustrate RHTT’s support for stateful abstract data types 
(ADTs), and their interaction with information flow. Working 
with ADTs essentially requires a number of higher-order 
features. For example, to support linked lists in a reasonable 
way, it has to be possible to: (1) describe the layout of the 
lists in the heap (is the list singly-linked, doubly-linked, etc?). 
This requires quantification in the assertion logic, definition of 
predicates by recursion, and inductive definitions of types; (2) 
abstract the definition of the heap layout from the specification 
of the ADT, so that the ADT clients can freely interchange 
implementations with different layouts (hence the need for 
abstract predicates); (3) parametrize the ADT with respect to 
the type of list elements (hence the need for type polymor¬ 
phism in both programs and the assertion logic). All of these 


linkedjist : type 

shape : linkedjist —> list T —*■ heap —> prop 
sshape (pp : linkedjist 2 ) (vvs : (list T) 2 ) (ii : heap 2 ) = 
shape pp. 1 vvs. 1 ii.l A shape pp. 2 vvs. 2 ii. 2 
lowjinks : linkedjist 2 —> heap 2 prop 

new : STsec nil linkedjist 
(fun i.True, 

fun pp ii mm. 3 jj. mm = jj •• ii A 
sshape pp (nil, nil) jj A (ii. I = ii. 2 —> lowjinks pp jj)) 

insert: STsec [linkedjist, T) unit 

(fun p v i.3h j vs. i = j • h A shape p vs j, 
fun pp vv yy ii mm.Vhh jj vvs. 

H = jj •• hh — > sshape pp vvs jj — > 

3 jj'. mm = jj' •• hh A 

sshape pp (vv.l::vvs.l, vv.2::vvs.2) jj' A 
(lowjinks pp jj —¥ hh. 1 = hh.2 —► lowjinks pp jj')) 

remove : STsec [linkedjist] (option T) 

(fun p i. 3 h j vs. i = j • h A shape p vs j, 
fun pp yy ii mm.Vhh jj vvs. 

H = jj •• hh —> sshape pp vvs jj —► 

3 jj'. mm = jj' •• hh A 

sshape pp (tail tws.1, tail vvs.2) jj' A 

yy = (if vvs. 1 is vl::_ then some vl else none, 

if vvs.2 is v2::_ then some v2 else none) A 
(lowjinks pp jj —► lowjinks pp jj')) 

Fig. 5. ListSig: signature for linked lists (excerpts). 

features are present in RHTT, and used in the Figures 5 and 6, 
which show one possible interface, ListSig, and a module. 
List, implementing ListSig. The interface exports methods that 
create a new empty list, insert an element to the head of a list, 
and remove the head element, should one exist. 

Both ListSig and List are parametrized in the type of list 
elements T. The interface declares the abstract predicate 
shape p vs 1, capturing that the heap i stores a valid singly- 
linked list whose content is the mathematical (i.e., purely- 
functional) sequence vs of type list T. The pointer p stores 
the address of the list head, so that adding new elements at 
the head can be done by updating p. The linkage between the 
elements is described by the predicate Iseq x vs which recurses 
over the contents vs and states that each node, starting from 
the head x, contains a single pointer z to the next node in the 
linked fist. The interface hides the details of shape, however, 
and can thus be ascribed to other implementations of shape, 
such as ones describing doubly-linked lists. 

The interface in Figure 5 contains one more abstract pred¬ 
icate lowjinks pp ii, which we use in combination with 
sshape pp vvs ii, to describe that the linkage of the list stored 
in the heap ii is of low security, no matter the security levels 
of the contents vvs. The latter may be heterogeneous; that is, 
some elements of vvs may be of low security, while others 
are high. Similar to Iseq, lowjinks recurses over the linked 
lists, declaring that each node is stored at a low address; that 


is, an address which is equal in the two heap instances, ii. 1 
and ii. 2. (The formal definition of low_links is elided here but 
appears in file Ilist3.v of the Coq scripts.) 

The types of the methods declare how the methods modify 
the contents of the list as well as the linkage. For example, 
the shape predicate in the preconditions of insert and remove 
requires that the initial heaps of these methods store valid 
linked lists. The sshape predicate in the postconditions guar¬ 
antees that valid linked lists are produced at the end. The 
postconditions additionally contain conjuncts describing that 
the methods preserve the low security level of the linkage. For 
example, new will allocate a fresh pointer p, and initialize it 
with null. If the deterministic allocator is used to obtain p, 
then p will be low only if the allocator is executed in low- 
equivalent initial heaps. Thus, in order to get lowjinks pp jj, 
we require an antecedent ii. 1 = ii. 2. Similarly, insert specifies 
that low_links pp jj —r hh. 1 = hh .2 —> lowjinks pp jj'. 
In other words, if the initial lists have low linkage, and the 
remainders of the global heaps are low equivalent, then we 
can allocate a list node with low linkage. This is so, because 
the initial heaps must be low equivalent under the described 
conditions. 

The implementations of the methods are standard (Figure 6), 
but due to the combinator syntax, we describe them in prose, 
new returns a fresh pointer, initialized with null. This will be 
the pointer p in the shape predicate, insert takes the pointer p 
to the list, and a value v to insert. It reads the address of the 
first element (bound to variable hd ), and allocates a node x 
whose contents field is v and next pointer field is hd. Finally, 
x is written to p. remove reads the address of the first element 
of the list p into the variable hd. If hd is null, then the list 
is empty, and the function terminates. Otherwise, it reads the 
contents of the node at hd, binding it to the variable v. p is 
made to point to next v, before v is deallocated. 

To establish that the implementation satisfies the signature, 
we need a number of helper lemmas about Iseq and linkedjist, 
which are kept local to the module. For example, for Iseq, we 
need properties that describe the behavior of Iseq x vs i, in 
case a; is null (then the whole list is empty), and non-null (then 
x points to the head). For low_links, we show that if two heaps 
store lists with low linkage and equal contents, then the heaps 
themselves are equal. 

Example 9. The program P 5 in Figure 7 illustrates heteroge¬ 
neous lists, i.e., lists that contain both high and low values. It 
takes a high boolean argument b, creates a new linked list, and 
inserts 0 (a constant, hence low) at the head. Then, depending 
on b, it inserts either 1 or 2, resulting in a heterogeneous 
list with a high first element and low second element. This is 
described in the postcondition by conditionals over the values 
of b in the two different runs (66.1 and 66.2). Irrespective of 
the contents, the ending linkage is low, assuming we started 
with low-equivalent input heaps. 

Example 10. The program P 6 in Figure 7 is similar to P 5 , but 
branches on b to decide whether to remove the head element. 
Therefore, the length of the resulting list may differ in the 


linked_list = ptr 
node : type = node of (T x ptr) 
elem (e : node) = e.l 
next (e : node) m e.2 
Iseq (x : ptr) (vs : list T ) : heap -»■ prop = 
if vs is v:\vt then 
fun i. 3^:ptr j:heap. 

i = x>-> node v z • j A Iseq z vt j 
else fun i.x = null A i = empty_heap 
shape (p : linkedjist) (vs : list T) (i : heap) = 

3a;:ptr. j:heap. i = p\-t x • j A Iseq x vs j 

new = do (lalloc @ 0 null) 
insert = 

do (read @ (fun p v.p)-, 

lalloc @ (fun hd p v. node v hd)-, 
write @ (fun x hd p v. (p, x))) 
remove = 

do (read @ (fun p.p); 

if (fun hd p. hd = null) then 
return @ (fun hd p. none) 
else 

read @ (fun hd p. hd)-, 

write @ (fun v hd p. (p, next v )); 

dealloc @ (fun _v hd p. hd)-, 

return @ (fun_ v hd p.some (elem v))) 

Fig. 6. Module List: implementation of singly-linked lists (excerpts). 

P 5 : STsec [bool] linkedjist 
(fun 6 A True, 

fun 66 yy ii mm. 3jj. mm = jj •• ii A 
sshape yy ([if 66.1 then 1 else 2,0], 

[if 66.2 then 1 else 2,0]) jj A 
(ii. 1 = ii. 2 —¥ lowjinks yy jj)) = 
do (new @ (fun 6. ()); 

insert @ (fun p b. (p,0)); 

if (fun _ p 6.6) then insert @ (fun _ p 6. (p, 1)) 
else insert @ (fun _p 6. (p, 2)) fi; 
return @ (fun_ p b.p)) 

P 6 : STsec [bool] linkedjist 
(fun 6 A True, 

fun 66 yy ii mm. 3jj. mm = ii •• jj A 
sshape yy (if 66.1 then [0] else [1,0], 

if 66.2 then [0] else [1,0]) jj) = 
do (new @ (fun 6. ()); 

insert @ (fun p b. (p,0)); 
insert @ (fun _ p 6. (p, 1)); 

if (fun_ p 6. 6) then 

remove @ (fun_ p b.p)-, 

return @ (fun_ p b.p) 

else return @ (fun_ p b.p)) 

Fig. 7. Programs with heterogeneous lists. 


two runs, depending on 6. We can specify it with the type 
shown in the Figure. Notice however that we cannot prove 
that low_links yy jj holds at the end of P 6 . The length of 
the produced list is dependent on b, which implies that the 
resulting linkage may differ in two runs of Pa, and hence 
cannot be low itself. 

Our Coq scripts implement other interfaces for linked list, 
where the sshape predicates are parametrized by the linkage as 
well. This exposes more implementation details (e.g., that the 
list is singly-linked), but allows more precise reasoning about 
linkage. For example, we may prove that executing one more 
conditional over b, with a call to remove in the else branch, 
will restore the low linkage. 

We are not aware of any other system in literature that 
can reason statically about heterogeneous structures. In the 
dynamic setting, a recent example is the work of Russo et 
al. [37], which tracks information-flow through DOM trees, 
with the goal of preventing information leakage via node 
deletion or navigation. The system works by assigning to each 
node two security labels: one for the contents, and another 
for the existence of the node. These annotations are very 
specific to DOM trees, however, and it seems that the label 
assignment would have to be designed differently for different 
data structures and enforced properties. Thus, if one wants to 
work with a number of structures simultaneously, one must 
employ a very rich specification logic, just as we do. 

We close with an example which combines linked lists with 
the Alice module from Section II. 

Example 11. In Example 5, Alice ratifies Bob’s tax function, 
which may keep local state, as long as Bob can prove that his 
final state does not steal Alice’s salary. Here we instantiate 
Bob’s local state to a linked list, which dynamically grows 
as various instances of Alice execute Bob’s program, but 
the values stored in the linked list are always independent 
of any instance’s salary and the list’s linkage is always low. 
Observe from the specifications of new and insert that Bob’s 
newly allocated nodes will be low only if he can generate 
them in low-equivalent heaps. To express this low equivalence 
the specification of epost used in ratify’s specification must 
change as emphasized below. 

epost aa bb jj yy ii mm = 

Vss pp kk tt hh. 

ii = jj •• tt •• hh —> sshape aa ss pp jj —r 
bbshape bb kk tt —r 

E jj' tt'. mm = jj' •• tt' •• hh A sshape aa ss pp jj' A 
bbshape bb (bcmp tt.l,bcmp kk. 2) tt' A 
\jj.l • hh.l = jj.2 • hh.2 | —>■ 
tt. 1 = tt.2 tt'.i = tt'.2 ) 

Bob can now be granted access to Alice’s salary and can keep 
the count in a linked list. For example, the implementation 
below defines Bob’s local state as a linked list which counts 
the number of times Bob’s program has been called by 
linking in new nodes into Bob’s list. The nodes are filled 
with 1 for simplicity, but arbitrary values would do, including 


dynamically computed ones, as long as they are independent 
of Alice’s salary. 

bob = linked_list 
G = list nat 

bbshape (bb : bob 2 ) (kk : G 2 ) (ii : heap 2 ) = 

List.sshape bb kk ii A 66.1 = 66.2 
bcmp : G G = fun k. 1 :: k 
Bob’s program, which reads Alice’s salary, allocates a new 
node in his list, and then returns the computed tax for the 
salary, can then be created and ratified as follows. 

Iinked_client = 

ratify (do (read_salary @ (fun a 6. a); 

insert @ (fun x a b. (6,1)); 
return @ (fun _x a b.x* 24%))) 

V. Discussion 

Completeness: We have informally justified the com¬ 
pleteness of our system through several examples, covering 
a wide range of security relevant policies including access 
control, information flow, declassification, erasure, and their 
combinations. Unfortunately we are not aware of a clear 
and exhaustive formal definition of what constitutes, say, an 
erasure, or access-control policy, or a combination thereof. 
Therefore, we do not know how to state a formal completeness 
result. 

If we focus on Cook completeness for RHTT, then, as we 
have argued in Section III, our specifications for all of the 
primitive effectful combinators compute weakest preconditions 
and strongest postconditions using the specifications of the 
components. The exception are the conditionals, for which this 
cannot be done when the boolean guard is high. However, 
RHTT is still capable of checking high conditionals against 
programmer-supplied postconditions. The lack of Cook com¬ 
pleteness therefore results in an increase in code annotations 
that the programmer has to supply, but does not decrease the 
reasoning power of the logic. 

Noninterference for finite security lattices: The standard 
notion of noninterference when locations are classified into 
elements of a security lattice is compatible with RHTT and 
can be expressed in postconditions of RHTT programs. If 
each variable of a program is classified at some level of a 
finite lattice L, then the program is noninterfering if for each 
£ £ L, the following holds: (xx\.\ = xx-\. 2 A ... A xx n . 1 = 
xx n .2) ->■ (S/3/i-1 = 2/2/1-2 A ... A yy m .l = yy m -2) where 
xxi,..., xx n are pairs of values of variables at or below 
security level £ in the two initial heaps and 3/2/1,..., yy n are 
pairs of values of variables at security level £ in the two 
final heaps. If the lattice L is finite, then the noninterference 
property can be represented in the postcondition of a program 
as the conjunction of such requirements for each level £ 6 L. 

This representation can be combinatorially explosive, if one 
uses one conjunct for each variable. But, in our higher-order 
assertion logic we can introduce predicates that abstract over 
a number of such conjuncts at once, and hence avoid the 




explosion. For example, if the variables in question all stand 
for the contents of some linked list, we can define a predicate 
that conjoins equations of the above form for each value 
reachable from the head of the list. Note that reachability can 
be expressed in higher-order but not in first-order logic. We 
leave a more detailed exploration of the above representation 
to future work. 

On proof sizes: We have found that the size of interactive 
proofs is not too overwhelming in general. However, the 
amount of interaction varies with programs. Programs with 
complex loop invariants usually require large proofs, whereas 
simpler programs can be verified in just a number of lines 
proportional to the size of the program. 

Programs that branch on high boolean guards invariably 
have larger proofs than programs that branch only on low: 
the latter always choose the same branches of conditionals 
in two runs, so the verification of the two runs proceeds 
in lockstep. High-branching programs can choose branches 
asymmetrically, thus doubling the number of proof obligations. 
In addition, when branches are chosen asymmetrically, the 
proofs usually require some mathematical insight from the pro¬ 
grammer (for example, algebraic simplification of expressions) 
in order to argue that the high secret has not been leaked. The 
latter, however, seems unavoidable, and inherent to the nature 
of programs branching on high guards. 

To substantiate, consider the programs from Examples 2 
and 3, our first examples that do not branch on high. We 
have the following statistics given as the pair ( code+spec 
size, proof size). For new, we have (7, 5); for read_salary 
(7, 4); for write_salary (18, 15) and for declassify (11, 5). The 
above proofs share common definitions and lemmas which are 
altogether 10 lines long. 

The program P 2 in Example 1, which contains nested 
conditionals and branching on high, is implemented using 
36 lines of code, most of which are inlined user-supplied 
annotations. The corresponding proof is 44 lines long. 

We have also implemented examples that iterate over linked 
data structures (not presented in the paper, but available in 
the accompanying Coq scripts). In a program for in-place list 
reversal, in which the linkage of the list is high, the code and 
annotations together take 43 lines. The proof is 94 lines long, 
because there is a high conditional branching on a null-pointer 
check. 

VI. Related work 

Banerjee et al. [7] specify expressive declassification poli¬ 
cies using Hoare style specifications (termed flowspecs); pre¬ 
conditions thereof are conjunctions of ordinary state conditions 
based on first-order logic (for specifying conditions when 
declassification can happen) as well as relational predicates 
(that specify what is being declassified) [39]. We extend the 
ideas in [7] and consider a higher-order imperative language 
and also a policy specification language based on higher-order 
logic, where Hoare-style specifications may appear in negative 
(i.e., argument) positions, which is required for conditional 
access and erasure policies. 


A recent line of work [23, 36] uses type-theoretic technol¬ 
ogy, namely Haskell, to specify and enforce information-flow 
properties in a non-dependently-typed setting. While Haskell 
already provides the important higher-order constructs for 
abstraction and modularity, non-dependent types by definition 
cannot specify behaviors that are dependent on some condition 
such as authorization, conformance to a policy, or local state. 
Thus, we do not think they can be used directly to enforce 
involved security policies such as the ones considered in this 
paper. 

Some other recent languages, with somewhat similar high- 
level goals to ours, and which use some form of dependent 
types are Fine [41], Fable [42], FX [10], Aglet [27], F7 [11] 
and Aura [20]. They all support some, but not all features that 
we provide in RHTT. 

In Swamy et al.’s purely functional programming language 
Fine [41], access and information flow policies can mention 
attributes like high and low, that statically label data. The type 
system enforces these policies by tracking flows of attributes. 
Unlike RHTT, Fine’s type system does not track changes to 
the state (heap), so the effect of state in policies must be 
simulated through ghost variables, whose (static) updates are 
governed by specifications of primitive functions. A token 
passing mechanism based on affine kinds ensures that at 
most one static state is valid at each program point, but it 
makes programming in Fine inconvenient. Fine includes a 
simple module system which allows a programmer to hide 
type definitions, but does not allow abstraction over predicates 
as RHTT does. In an earlier language. Fable [42], data can be 
statically labelled with attributes that can be used to enforce 
both access control and information flow policies. However, 
Fable’s type system lacks the affine kinds of Fine as well 
as Fine’s logic-based sublanguage for policies and, therefore, 
cannot be used to reason about state-dependent policies. 

The language FX [10] succeeds Fine with the purpose 
of verifying stateful programs that permit object allocation, 
mutation and deallocation. The type system of FX admits 
computation (Hoare) types and caters to the verification of 
safety properties of FX programs by translating into Fine 
programs and typechecking the latter. The translation is a 
simulation under strong bisimilarity, rather than the stronger 
property that well-typed FX programs are translated into well- 
typed Fine programs. The verification of security policies, 
particularly, of non-safety properties such as noninterference, 
is not the overarching goal of FX’s type system, although a 
lattice of labels can be encoded and used to prove, e.g., an 
integrity property that untrusted data does not get consumed at 
trusted sinks. A proof of noninterference is not supplied; as in 
most label-based security type systems, such a proof cannot be 
carried out in FX’s (or Fine’s) type system directly (in contrast 
to our work) but rather must be established as a metatheorem 
of the type system by reasoning about two runs of programs. 
As regards reasoning about stateful higher-order programs, the 
formalization is left for future work and we expect that it 
will elucidate how the type system reasons about (security 
properties of) unbounded dynamic data structures e.g., linked 


lists, trees with back pointers etc., that contain significant use 
of aliased mutable objects. In particular, because FX proposes 
to reason about aliasing using a hbrary of permissions the 
above formalization might be delicate. 

Morgenstern and Licata have recently proposed a type 
system called Aglet [27], for enforcement of state-dependent 
access control policies. Aglet is an extension of Agda [33] with 
a computation monad similar to our STsec types. However, 
Aglet’s computation monad lacks semantics and, consequently, 
the soundness of its inference rules has to be taken on faith (in 
contrast, the RHTT model is formalized in Coq). Moreover, 
the pre- and post-conditions of Aglet’s computation monad 
can only mention a restricted form of state, namely, a mutable 
list of authorization-relevant credentials, which can be used to 
discharge authorization obligations at various program points. 
Due to this restriction, Aglet cannot be used to reason about 
data structures written in Agda. Also, Aglet’s postconditions 
do not consider simultaneous runs of programs. As a result of 
these limitations, Aglet cannot be used to represent many of 
our examples. On the other hand, we believe that examples 
from the paper on Aglet can be expressed in RHTT easily. 

Borgstrom et al. [11] reason about access control behavior 
of programs in an extension of F7 that has a state monad 
with pre- and post-conditions. Although the state monads in 
their work and ours are technically similar, that work differs 
from ours in two significant ways. First, the goals are dif¬ 
ferent: whereas we consider enforcement of information flow 
properties and declassification in addition to access control 
properties, Borgstrom et al. consider access control and show 
how the state monad can be used to enforce different flavors 
of it, viz. role-based, stack-based, and history-based. Second, 
in common with other work based in F7, a priori evidence for 
discharging verification conditions in Borgstrom et al’s work 
is programmer specified assumptions that are not necessarily 
semantically grounded, and verification is correct only to the 
extent that these assumptions are correct. In contrast to their 
axiomatic approach, we verify the soundness of our type 
theory on a semantic model. Nonetheless, due to the common 
state-monad based approach, and RHTT’s more general type 
system, we believe that Borgstrom et al’s work can be encoded 
in RHTT without much change. As a first step in this direction, 
our Coq scripts contain an example that shows how RHTT 
supports reasoning about principals and roles. 

The languages Aura [20], PCML 5 [5], and PCAL [13], 
based on the proof-as-authorization paradigm [2], enforce 
logic-represented access policies by statically ensuring that 
each call to a protected interface is accompanied by proper 
authorization. Although work in the context of Aura shows 
that noninterference can be encoded [21], Aura currently does 
not handle state in the form that we consider in this paper. 
However, it is conceivable that mutable state can be added to 
Aura along the lines of the STsec monad. 

The Paralocks language [12] also allows logic-based access 
control policies that are enforced statically in the type system. 
Information flow policies can be encoded as a specific mode 
of access control as, for instance, is demonstrated through an 


encoding of Myers’ and Liskov’s Decentralized Label Model. 
Like Fine, Paralocks includes two kinds of state, of which, one, 
called locks, is tracked through the type system, while the other 
is not. Locks are boolean variables that can be used to encode 
a wide range of policies. The semantics of Paralocks is trace- 
based and, like gradual release [3], uses a knowledge-based 
definition of information leaks. A meta-theorem guarantees 
that access policies of a well-typed program are respected at 
all program points during the program’s execution. 

Finally, RHTT extends the work on Hoare Type Theory 
(HTT) [31] and Ynot [30] with the ability to reason relationally 
about security. HTT and Ynot implement via dependent types 
a higher-order variant of Hoare logic for single program runs. 
Thus, they cannot enforce relational properties such as the 
various information flow policies, which are specified via two 
program runs. A more technical discussion of the differences 
between these systems and RHTT appears in the TR. 

VII. Conclusion 

We have presented RHTT, a system implemented in Coq 
that is targeted for full interactive verification of state-based 
access control and information flow policies via dependent 
types. Examples of such security policies include declassi¬ 
fication, information erasure and state-based access control 
and information flow. We have presented typing rules for the 
stateful fragment of RHTT and implemented a semantic model 
that provides a denotation to every well-typed RHTT program. 
We have also developed a logic for discharging verification 
conditions that arise in the verification process. 

Currently, RHTT does not support reasoning about trace- 
based, temporal properties. For example, while it is intu¬ 
itively clear that our specification of functions grant, revoke, 
read_salary (Example 4) indeed encodes a temporal discipline 
on the usage of read_salary (e.g., “no reads occur unless a 
grant has occurred and no revoke has occurred after the grant”) 
this cannot be formally proved in our logic itself. We note 
that very little is known on how enforcement of trace-based 
properties, in security or other areas such as concurrency, 
interacts with type theoretic constructions such as higher-order 
functions, abstract types or modules. We intend to investigate 
this in the future, in the context of reactive, non-deterministic 
and concurrent higher-order languages. 
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